The latest updates on your projects. Learn more about Vercel for Git ↗︎

I would suggest to reference the observer node as "Light Node" (not "light client").

To the best of my knowledge, there is no properly defined terminology. However, in the context of Flow, there is an important differentiation between what I call a light node vs a light client:

Light Node (previously called Observer)

• The light nodes are designed to be continuously online and:
  • observes consensus, by downloading and indexing the blocks (though not the execution state)
  • locally store a continuous history of blocks (the history doesn't need to go back to genesis, but they are generally keeping a longer history of blocks)
  • locally validate that consensus rules are followed
• The important aspect detail is: observers only work if they have a continuous history of blocks. They can be offline, but have to catch up before they can answer queries about recent blocks.
• It can (but doesn't have to) replicate some of the execution state, store it locally, index the replicated part of the state.
• To run a Light Node, you need a dedicated computer (maybe only laptop-grade hardware, but at least that depending on how much execution state you want to store locally and how compute-intensive your state queries are) which should be continuously online.
• Reasons people might want to run an observer:
  • they care about more than a few accounts
  • they want to execute frequent and complex state queries, where it is more efficient to replicate some of the execution state (with a limited history) locally, validate its integrity once and then work with the local (already validated) state data
  • low latency of state and event queries
  • enterprise-level security or reporting requirements (e.g. exchanges, professional investors, governments, etc)

From a software perspective, the Light Node is quite similar to the archive node (store and index blocks, store and index execution state), except that is does not exhaustively replicate the entire execution state and does not commit to keeping a super-long history .

Light Client

• We are architecting light clients to run on embedded hardware (phones, raspberry Pi, smart-home devices and high-end spectrum of micro controllers). These either do not have the hardware resources (in the case of micro controllers), or the user does not want to expend the hardware resources (e.g. phones) to continuously follow the blocks and index them.
• A light client achieves this by not validating consensus on a continuous basis, but instead receiving consistency proofs that a supermajority of consensus nodes have committed the respective data.
• Light clients are safe. Just that they won't be able to notice some attacks on the network that observers would be able to detect. So in a sense, Light clients do not really contribute to network safety, observers contribute a bit (they validate consensus), and full nodes contribute a lot (validate consensus and secure the network additionally through their role-specific tasks)
• Light Clients are designed to only store negligible amounts of execution state locally. Essentially all data is fetched on demand (integrity cryptographically validated locally).
• Light Clients are designed for the consumer
  • with a few accounts
  • largely interested about changes of these accounts
  • does not want to run a client continuously
  • can wait some seconds (maybe a minute when the client was offline for weeks) until most recent state of their accounts has been loaded
  • does not want to keep long history (via their light client)
  • does not want to run dedicated hardware to trustlessly interact with the chain

More details on light clients:

• Upgrading Flow's Consensus Follower to boost attack resilience and processing speed
• Flow’s Data Egress: A Long-Term Vision

Context:

• While light clients are not here yet, we are working towards them. So I think we should shape our terminology such that we have a term for them.

I would suggest to reference the observer node as "Light Node" (not "light client").

To the best of my knowledge, there is no properly defined terminology. However, in the context of Flow, there is an important differentiation between what I call a light node vs a light client:

Light Node (previously called Observer)

• The light nodes are designed to be continuously online and:

  • observes consensus, by downloading and indexing the blocks (though not the execution state)
  • locally store a continuous history of blocks (the history doesn't need to go back to genesis, but they are generally keeping a longer history of blocks)
  • locally validate that consensus rules are followed

• The important aspect detail is: observers only work if they have a continuous history of blocks. They can be offline, but have to catch up before they can answer queries about recent blocks.

• It can (but doesn't have to) replicate some of the execution state, store it locally, index the replicated part of the state.

• To run a Light Node, you need a dedicated computer (maybe only laptop-grade hardware, but at least that depending on how much execution state you want to store locally and how compute-intensive your state queries are) which should be continuously online.

• Reasons people might want to run an observer:

  • they care about more than a few accounts
  • they want to execute frequent and complex state queries, where it is more efficient to replicate some of the execution state (with a limited history) locally, validate its integrity once and then work with the local (already validated) state data
  • low latency of state and event queries
  • enterprise-level security or reporting requirements (e.g. exchanges, professional investors, governments, etc)

From a software perspective, the Light Node is quite similar to the archive node (store and index blocks, store and index execution state), except that is does not exhaustively replicate the entire execution state and does not commit to keeping a super-long history .

Light Client

• We are architecting light clients to run on embedded hardware (phones, raspberry Pi, smart-home devices and high-end spectrum of micro controllers). These either do not have the hardware resources (in the case of micro controllers), or the user does not want to expend the hardware resources (e.g. phones) to continuously follow the blocks and index them.

• A light client achieves this by not validating consensus on a continuous basis, but instead receiving consistency proofs that a supermajority of consensus nodes have committed the respective data.

• Light clients are safe. Just that they won't be able to notice some attacks on the network that observers would be able to detect. So in a sense, Light clients do not really contribute to network safety, observers contribute a bit (they validate consensus), and full nodes contribute a lot (validate consensus and secure the network additionally through their role-specific tasks)

• Light Clients are designed to only store negligible amounts of execution state locally. Essentially all data is fetched on demand (integrity cryptographically validated locally).

• Light Clients are designed for the consumer

  • with a few accounts
  • largely interested about changes of these accounts
  • does not want to run a client continuously
  • can wait some seconds (maybe a minute when the client was offline for weeks) until most recent state of their accounts has been loaded
  • does not want to keep long history (via their light client)
  • does not want to run dedicated hardware to trustlessly interact with the chain

More details on light clients:

• Upgrading Flow's Consensus Follower to boost attack resilience and processing speed
• Flow’s Data Egress: A Long-Term Vision

Context:

• While light clients are not here yet, we are working towards them. So I think we should shape our terminology such that we have a term for them.

❤️ thank you for this explanation - will change Light Client to Light Node

@AlexHentschel @peterargue - Just wanted to call out - I am intentionally avoiding the phrase light node previously known as observer node and instead saying light node a.k.a. observer node since the word observer node is far too prevalent in our documentation, past communications and even in the docker image.
Forcing a rename now will just lead to a lot of confusion.